\section{Analyse af SCRUM}

\textit{Da vi første gang blev introduceret for SCRUM på vores tredje semester, virkede arbejdsmetoden som den absolut bedste løsning til at tage hånd om de problemer og vanskeligheder, som kan opstå ved styring og planlægningen af et projekt. SCRUM blev serveret som den gyldne løsning, og det lød som om det var lige til at gå til. Vi er dog blevet klogere og vil i dette afsnit analysere om SCRUM overhovedet kan være en hjælp. Vi vil først komme ind på nogle af de ting der fungerede i vores SCRUM, senere vil vi analysere de ting som virkede mindre godt.}

\subsection{Virtuelt SCRUM-board}

Som beskrevet tidligere, var noget af det første vi gjorde at lave et Virtuelt SCRUM-board. Dette brød en smule med SCRUM principperne, da SCRUM foreslår at man bruger et fysisk board. Dette var imidlertid en god beslutning, da vi ikke havde mulighed for at mødes hver dag eller mødes i det samme lokale. Så vores virtuelle SCRUM-board, gjorde os i stand til at følge hinandens process selvom vi ikke havde mulighed for at mødes fysisk hver dag. Vores board var en SCRUM-But, men det var en SCRUM-But på den gode måde, da den gjorde os i stand til at gennemføre SCRUM selvom vi ikke havde de optimale arbejdsvilkår.

\subsection{Estimering}

Et andet SCRUM princip der fungerede rigtigt godt i vores projekt var estimeringsmetoden. SCRUM giver nogle meget klare retningslinjer for hvordan prioritering, estimering og uddelegering af tasks skal foregå. SCRUM gjorde det på denne måde overskueligt at komme i gang med projektet. Helt konkret viste det sig at være en stor hjælp at vide, hvor langt vi var fra at have implementeret specifikke metoder i koden. Det gav en sikkerhed overfor SMU, at vi kunne melde ud hvornår forskellige funktionaliteter kom til at virke, men derudover også klare linjer for os i gruppen.

\subsection{Misligholdelse af SCRUM-principper}

Da vi i uddannelsesøjemed brugte SCRUM i vores projekt, fandt vi hurtigt ud af at der opstod nogle komplikationerne med den oprindelige idé om en velfungerende SCRUM arbejdsgang. Vi kunne eksempelvis ikke holde daily meetings hver dag, grundet andre igangværende projekter fra andre kurser. Vores rollefordeling var præget af fiktive inddelinger, idet vi alle var med til at finde ud af hvilke behov systemet skulle varetage, hvilket normalt er en product owners arbejdsområde. Dertil havde SCRUM masteren to funktioner, idet vi ikke havde kapacitet til at undvære en programmør i vores team.
\\\\
Disse SCRUM-Buts gik på kompromis med effektiviteten og den gennemslagskraft en rigtig SCRUM arbejdsgang kan have. Ved ikke at have daily meetings hver dag, faldt de gode konstruktive snakke lidt til jorden. Vi fik ikke helt sumeret op på de problemstillinger vi hver især var løbet ind i, fordi vi simpelthen var kommet ud af SCRUM flowet og havde lagt problemerne lidt på hylden. Rollefordelingerne fik heller ikke den funktion som var idéen med dem, idet det hele var et lidt “falsk” setup af en product owner, repræsenteret ved samtlige gruppemedlemmer og en SCRUM master som ikke helt havde mulighed for at fokusere på kun at planlægge arbejdsgangen for programmørerne. Derudover havde vores SCRUM master, som resten af gruppen, meget begrænset erfaring med SCRUM. Dette gjorde det svært for SCRUM masteren at have det forkromede overblik som skulle til, for at få planlægning til at fungere optimalt.

\subsection{Delkonklusion}

Efter arbejdet med SCRUM har vi som nævnt stødt ind i forskellige problemstillinger, men også gode ting ved denne arbejdsmetode. Vi kan spørge os selv om SCRUM overhovedet var det rette valg? Halvvejs igennem vores projekt blev vi induceret til søstjerne-modellen \citep[slide 2]{agilvsplan29apr2013}, som kan bruges til at vurdere om projektet egner sig til SCRUM. Vi har som refleksion valgt at udfylde modellen for at se om SCRUM overhovedet egner sig til vore projekt.

\begin{figure}[H]
	\centering
	\includegraphics[width=\textwidth]{Pictures/Soestjerne.jpg} 
	\caption{Illustrerer vores projekts søstjerne profil.}
\end{figure}

Arbejdsbyrden kan godt blive for stor ved indførelse af SCRUM, hvis projektet er af en for lille størrelse. Modellen viser at vores projekt egner sig til SCRUM, grundet projektets størrelse og at fejl som opstår, ikke har de store konsekvenser. Kravene, som i projektet er meget flyvske, grundet samarbejdet med Singapore, gør også brugen af SCRUM til en god løsning. På den anden side ligner projektet ikke noget andet vi har lavet, og det at projektteamet generelt er uerfarent, gør at SCRUM er et knap så favorabelt valg. Netop denne uerfarenhed, har vi måtte erfare at være hovedårsagen for vores manglende udbytte af SCRUM.
\\\\
At bruge elementer som SCRUM board og estimeringstabeller, har været et effektivt hjælpemiddel for at planlægge ugerne og projektets forløb, men vi synes ikke at vi har fået det fulde udbytte af SCRUM som arbejdsværktøj, idet nogle af de essentielle dele af SCRUM principperne ikke blev overholdte.